Skip to content

chore(localizations): Added missing pt-BR translations #6503

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Aug 13, 2025

Conversation

fell-lucas
Copy link
Contributor

@fell-lucas fell-lucas commented Aug 10, 2025

Description

Adds missing ptBR translations that are available in the enUS translation file.

Checklist

  • pnpm test runs as expected.
  • pnpm build runs as expected.
  • (If applicable) JSDoc comments have been added or updated for any package exports
  • (If applicable) Documentation has been updated

Type of change

  • 🐛 Bug fix
  • 🌟 New feature
  • 🔨 Breaking change
  • 📖 Refactoring / dependency upgrade / documentation
  • other: Translation files

Summary by CodeRabbit

  • New Features
    • Completed Brazilian Portuguese (pt-BR) localization across the app: API keys, commerce/pricing, subscriptions, badges, dates, footer, and profile pages.
    • Added translations for sign-in/sign-up flows, passkeys, Web3 wallets, multi-factor auth prompts, and error messages.
    • Introduced localized organization selection and creation text and improved consistency of organization/user-facing strings.

Copy link

changeset-bot bot commented Aug 10, 2025

🦋 Changeset detected

Latest commit: 8d81a8d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages
Name Type
@clerk/localizations Patch
@clerk/clerk-js Patch
@clerk/chrome-extension Patch
@clerk/clerk-expo Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copy link

vercel bot commented Aug 10, 2025

@fell-lucas is attempting to deploy a commit to the Clerk Production Team on Vercel.

A member of the Team first needs to authorize it.

Copy link
Contributor

coderabbitai bot commented Aug 10, 2025

📝 Walkthrough

Walkthrough

A new changeset (.changeset/forty-bottles-accept.md) was added and the Brazilian Portuguese localization file (packages/localizations/src/pt-BR.ts) was updated. The pt-BR export now includes many completed translation strings across API keys, badges, commerce, subscriptions, sign-in/sign-up flows, passkeys, Web3 wallets, error messages, organization/user profiles, dates, organization switcher, and other UI labels. A new top-level property taskChooseOrganization was added to the ptBR object containing signOut, createOrganization, and chooseOrganization entries. No API or exported type declarations were changed.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9a8c32c and 8d81a8d.

📒 Files selected for processing (1)
  • packages/localizations/src/pt-BR.ts (17 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

**/*.{js,jsx,ts,tsx}: All code must pass ESLint checks with the project's configuration
Follow established naming conventions (PascalCase for components, camelCase for variables)
Maintain comprehensive JSDoc comments for public APIs
Use dynamic imports for optional features
All public APIs must be documented with JSDoc
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Profile and optimize critical paths
Validate all inputs and sanitize outputs
Implement proper logging with different levels

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{js,jsx,ts,tsx,json,css,scss,md,yaml,yml}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Use Prettier for consistent code formatting

Files:

  • packages/localizations/src/pt-BR.ts
packages/**/*.{ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

TypeScript is required for all packages

Files:

  • packages/localizations/src/pt-BR.ts
packages/**/*.{ts,tsx,d.ts}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Packages should export TypeScript types alongside runtime code

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Use proper TypeScript error types

**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs
Use proper type annotations for variables and parameters where inference isn't clear
Avoid any type - prefer unknown when type is uncertain, then narrow with type guards
Use interface for object shapes that might be extended
Use type for unions, primitives, and computed types
Prefer readonly properties for immutable data structures
Use private for internal implementation details
Use protected for inheritance hierarchies
Use public explicitly for clarity in public APIs
Prefer readonly for properties that shouldn't change after construction
Prefer composition and interfaces over deep inheritance chains
Use mixins for shared behavior across unrelated classes
Implement dependency injection for loose coupling
Let TypeScript infer when types are obvious
Use const assertions for literal types: as const
Use satisfies operator for type checking without widening
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Use type-only imports: import type { ... } from ...
No any types without justification
Proper error handling with typed errors
Consistent use of readonly for immutable data
Proper generic constraints
No unused type parameters
Proper use of utility types instead of manual type construction
Type-only imports where possible
Proper tree-shaking friendly exports
No circular dependencies
Efficient type computations (avoid deep recursion)

Files:

  • packages/localizations/src/pt-BR.ts
packages/localizations/**/*

📄 CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

Localization files must be placed in 'packages/localizations/'.

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{js,ts,tsx,jsx}

📄 CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

Support multiple Clerk environment variables (CLERK_, NEXT_PUBLIC_CLERK_, etc.) for configuration.

Files:

  • packages/localizations/src/pt-BR.ts
**/*

⚙️ CodeRabbit Configuration File

If there are no tests added or modified as part of the PR, please suggest that tests be added to cover the changes.

Files:

  • packages/localizations/src/pt-BR.ts
**/localizations/**/*.ts

⚙️ CodeRabbit Configuration File

**/localizations/**/*.ts: Review the changes to localization files with the following guidelines:

  • Ensure that no existing translations are accidentally removed unless they are being replaced or fixed. If a string is removed, verify that it is intentional and justified.
  • Check that all translations are friendly, formal, or semi-formal. Explicit, offensive, or inappropriate language is not allowed. If you find any potentially offensive language or are unsure, tag the @clerk/sdk-infra team in a separate comment. If you do not intend to tag the team, refer to it as "Clerk SDK Infra team" instead.
  • Use the most up-to-date base localization file (https://github.com/clerk/javascript/blob/main/packages/localizations/src/en-US.ts) to validate changes, ensuring consistency and completeness.
  • Confirm that new translations are accurate, contextually appropriate, and match the intent of the original English strings.
  • Check for formatting issues, such as missing placeholders, incorrect variable usage, or syntax errors.
  • Ensure that all keys are unique and that there are no duplicate or conflicting entries.
  • If you notice missing translations for new keys, flag them for completion.

Files:

  • packages/localizations/src/pt-BR.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: semgrep-cloud-platform/scan
🔇 Additional comments (12)
packages/localizations/src/pt-BR.ts (12)

17-36: LGTM! Comprehensive taskChooseOrganization translations added

The new translation group provides complete coverage for organization selection flow with contextually appropriate Portuguese strings. The translations are friendly, formal, and consistent with the existing style throughout the file.


38-69: API keys translations look good with previous feedback addressed

All the API key translations are well-implemented. I can see the previous feedback about time abbreviations and consistent terminology has been addressed:

  • Minutes now use "min" instead of "m" (line 59)
  • Months now use "mês(es)" instead of "m" (line 60)
  • Consistent use of "chave de API" terminology throughout (lines 67-68)

79-80: Badge translations completed appropriately

The pastDueAt and pastDuePlan badge translations properly convey payment overdue status in Portuguese.


105-106: Commerce error message translation is accurate

The cannotSubscribeUnrecoverable translation correctly conveys the subscription limitation scenario in clear Portuguese.


166-186: Subscription and commerce details translations are comprehensive

All subscription-related labels and commerce pricing strings are properly translated with appropriate Portuguese terminology. The pricing format strings maintain proper variable interpolation.


195-202: Date formatting translations use proper locale specifications

The date formatting strings correctly specify the 'pt-BR' locale for all temporal formatting functions, ensuring proper Brazilian Portuguese date/time display.


204-204: Footer link translation is appropriate

The alternative phone code provider link uses clear, actionable Portuguese text.


283-283: API keys page titles consistently use proper terminology

All instances of API keys page titles correctly use "Chaves de API" which maintains consistency across the user interface.

Also applies to: 405-405, 933-933, 1119-1119


723-723: Sign-in subtitle translation is contextually appropriate

The welcome message uses friendly, professional Portuguese suitable for a sign-in flow.


824-824: Social button translation uses proper formatting

The social button translation correctly uses the {{provider|titleize}} variable interpolation format.


831-847: Error message translations are clear and user-friendly

All the unstable error messages provide clear, actionable feedback in Portuguese:

  • Form validation errors are concise and helpful
  • Web3 wallet error message is descriptive and actionable
  • Organization domain error is appropriately specific

Also applies to: 862-862, 883-884


1223-1223: Passkey button translation is accurate

The primary button text for adding passkeys uses appropriate Portuguese terminology for "chave de acesso".


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🔭 Outside diff range comments (1)
packages/localizations/src/pt-BR.ts (1)

1058-1058: Untranslated string: “Add” should be localized

This is visible UI text; translate to pt-BR.

-    formButtonPrimary__add: 'Add',
+    formButtonPrimary__add: 'Adicionar',
🧹 Nitpick comments (2)
packages/localizations/src/pt-BR.ts (1)

1-1286: Tests and linting

No tests were added. Consider adding a key-coverage and placeholder-parity test (like the script above) to prevent regressions. Also ensure Prettier/ESLint pass for this file.

You can adapt the script above into a unit test to enforce parity with en-US.

.changeset/forty-bottles-accept.md (1)

1-6: Changeset looks correct; minor copy nit

Consider using hyphenated locale and imperative mood.

-added missing ptBR translations
+add missing pt-BR translations
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cf284ee and 416efa8.

📒 Files selected for processing (2)
  • .changeset/forty-bottles-accept.md (1 hunks)
  • packages/localizations/src/pt-BR.ts (17 hunks)
🧰 Additional context used
📓 Path-based instructions (10)
.changeset/**

📄 CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

Automated releases must use Changesets.

Files:

  • .changeset/forty-bottles-accept.md
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

**/*.{js,jsx,ts,tsx}: All code must pass ESLint checks with the project's configuration
Follow established naming conventions (PascalCase for components, camelCase for variables)
Maintain comprehensive JSDoc comments for public APIs
Use dynamic imports for optional features
All public APIs must be documented with JSDoc
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Profile and optimize critical paths
Validate all inputs and sanitize outputs
Implement proper logging with different levels

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{js,jsx,ts,tsx,json,css,scss,md,yaml,yml}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Use Prettier for consistent code formatting

Files:

  • packages/localizations/src/pt-BR.ts
packages/**/*.{ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

TypeScript is required for all packages

Files:

  • packages/localizations/src/pt-BR.ts
packages/**/*.{ts,tsx,d.ts}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Packages should export TypeScript types alongside runtime code

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Use proper TypeScript error types

**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs
Use proper type annotations for variables and parameters where inference isn't clear
Avoid any type - prefer unknown when type is uncertain, then narrow with type guards
Use interface for object shapes that might be extended
Use type for unions, primitives, and computed types
Prefer readonly properties for immutable data structures
Use private for internal implementation details
Use protected for inheritance hierarchies
Use public explicitly for clarity in public APIs
Prefer readonly for properties that shouldn't change after construction
Prefer composition and interfaces over deep inheritance chains
Use mixins for shared behavior across unrelated classes
Implement dependency injection for loose coupling
Let TypeScript infer when types are obvious
Use const assertions for literal types: as const
Use satisfies operator for type checking without widening
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Use type-only imports: import type { ... } from ...
No any types without justification
Proper error handling with typed errors
Consistent use of readonly for immutable data
Proper generic constraints
No unused type parameters
Proper use of utility types instead of manual type construction
Type-only imports where possible
Proper tree-shaking friendly exports
No circular dependencies
Efficient type computations (avoid deep recursion)

Files:

  • packages/localizations/src/pt-BR.ts
packages/localizations/**/*

📄 CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

Localization files must be placed in 'packages/localizations/'.

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{js,ts,tsx,jsx}

📄 CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

Support multiple Clerk environment variables (CLERK_, NEXT_PUBLIC_CLERK_, etc.) for configuration.

Files:

  • packages/localizations/src/pt-BR.ts
**/*

⚙️ CodeRabbit Configuration File

If there are no tests added or modified as part of the PR, please suggest that tests be added to cover the changes.

Files:

  • packages/localizations/src/pt-BR.ts
**/localizations/**/*.ts

⚙️ CodeRabbit Configuration File

**/localizations/**/*.ts: Review the changes to localization files with the following guidelines:

  • Ensure that no existing translations are accidentally removed unless they are being replaced or fixed. If a string is removed, verify that it is intentional and justified.
  • Check that all translations are friendly, formal, or semi-formal. Explicit, offensive, or inappropriate language is not allowed. If you find any potentially offensive language or are unsure, tag the @clerk/sdk-infra team in a separate comment. If you do not intend to tag the team, refer to it as "Clerk SDK Infra team" instead.
  • Use the most up-to-date base localization file (https://github.com/clerk/javascript/blob/main/packages/localizations/src/en-US.ts) to validate changes, ensuring consistency and completeness.
  • Confirm that new translations are accurate, contextually appropriate, and match the intent of the original English strings.
  • Check for formatting issues, such as missing placeholders, incorrect variable usage, or syntax errors.
  • Ensure that all keys are unique and that there are no duplicate or conflicting entries.
  • If you notice missing translations for new keys, flag them for completion.

Files:

  • packages/localizations/src/pt-BR.ts
🔇 Additional comments (6)
packages/localizations/src/pt-BR.ts (6)

17-36: New organization chooser translations read well

Wording is clear and semi-formal; placeholders look correct. No issues found.


281-283: API Keys titles/nav look consistent

The additions for API Keys in org and user sections are consistent and clear. No issues found.

Also applies to: 403-409, 931-933, 1116-1122


721-723: Sign-in combined subtitle is friendly and appropriate

Tone and phrasing look good for pt-BR. No issues found.


822-823: Social provider label (many-in-view) looks correct

Showing only the provider name matches expected pattern. No issues found.


829-845: Error messages look accurate and safe

Wording is clear, formal, and non-offensive. Placeholders appear correct.

Also applies to: 861-862, 882-883


1-1286: Confirm translation key and placeholder parity
I attempted to run the comparison script, but it didn’t emit any results. Please manually verify that:

  • pt-BR covers every key defined in en-US (no missing or extra entries)
  • Each {{…}} placeholder in pt-BR exactly matches its counterpart in en-US (no missing or stray variables)

tmilewski and others added 2 commits August 13, 2025 11:41
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (3)
packages/localizations/src/pt-BR.ts (3)

57-64: Resolved ambiguity for minutes vs months — good fix

Using “min” for minutes and “mês(es)” for months follows pt-BR conventions and removes ambiguity.


1249-1251: Likely wrong action label: should set wallet as primary, not “Conectar”

For consistency with other “detailsAction__nonPrimary” entries (e.g., email/phone), this action should set the wallet as primary.

Apply this diff:

-        detailsAction__nonPrimary: 'Conectar carteira',
+        detailsAction__nonPrimary: 'Definir como principal',

218-221: Placeholder should use “chave de API”, not “chave secreta”

One remaining inconsistency with the preferred terminology.

Apply this diff:

-  formFieldInputPlaceholder__apiKeyName: 'Digite o nome da sua chave secreta',
+  formFieldInputPlaceholder__apiKeyName: 'Digite o nome da sua chave de API',

Optionally also align creation button for clarity:

-    formButtonPrimary__add: 'Criar chave',
+    formButtonPrimary__add: 'Criar chave de API',
🧹 Nitpick comments (2)
packages/localizations/src/pt-BR.ts (2)

38-40: Terminology consistency: explicitly say “chave de API” in actions

To match other occurrences (titles, navbar, placeholders), prefer “chave de API” over generic “chave”.

Apply this diff:

-    action__add: 'Adicionar nova chave',
-    action__search: 'Pesquisar chaves',
+    action__add: 'Adicionar nova chave de API',
+    action__search: 'Pesquisar chaves de API',
@@
-    menuAction__revoke: 'Revogar chave',
+    menuAction__revoke: 'Revogar chave de API',

Also applies to: 65-66


15-16: Optional: add a parity check between en-US and pt-BR keys

No tests were added. Consider adding a lightweight check to ensure pt-BR keys stay in sync with en-US (e.g., a script that compares key paths or a TS-level “satisfies” check in CI). I can help draft this if you want.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 416efa8 and 9a8c32c.

📒 Files selected for processing (1)
  • packages/localizations/src/pt-BR.ts (17 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

**/*.{js,jsx,ts,tsx}: All code must pass ESLint checks with the project's configuration
Follow established naming conventions (PascalCase for components, camelCase for variables)
Maintain comprehensive JSDoc comments for public APIs
Use dynamic imports for optional features
All public APIs must be documented with JSDoc
Provide meaningful error messages to developers
Include error recovery suggestions where applicable
Log errors appropriately for debugging
Lazy load components and features when possible
Implement proper caching strategies
Use efficient data structures and algorithms
Profile and optimize critical paths
Validate all inputs and sanitize outputs
Implement proper logging with different levels

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{js,jsx,ts,tsx,json,css,scss,md,yaml,yml}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Use Prettier for consistent code formatting

Files:

  • packages/localizations/src/pt-BR.ts
packages/**/*.{ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

TypeScript is required for all packages

Files:

  • packages/localizations/src/pt-BR.ts
packages/**/*.{ts,tsx,d.ts}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Packages should export TypeScript types alongside runtime code

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/development.mdc)

Use proper TypeScript error types

**/*.{ts,tsx}: Always define explicit return types for functions, especially public APIs
Use proper type annotations for variables and parameters where inference isn't clear
Avoid any type - prefer unknown when type is uncertain, then narrow with type guards
Use interface for object shapes that might be extended
Use type for unions, primitives, and computed types
Prefer readonly properties for immutable data structures
Use private for internal implementation details
Use protected for inheritance hierarchies
Use public explicitly for clarity in public APIs
Prefer readonly for properties that shouldn't change after construction
Prefer composition and interfaces over deep inheritance chains
Use mixins for shared behavior across unrelated classes
Implement dependency injection for loose coupling
Let TypeScript infer when types are obvious
Use const assertions for literal types: as const
Use satisfies operator for type checking without widening
Use mapped types for transforming object types
Use conditional types for type-level logic
Leverage template literal types for string manipulation
Use ES6 imports/exports consistently
Use default exports sparingly, prefer named exports
Use type-only imports: import type { ... } from ...
No any types without justification
Proper error handling with typed errors
Consistent use of readonly for immutable data
Proper generic constraints
No unused type parameters
Proper use of utility types instead of manual type construction
Type-only imports where possible
Proper tree-shaking friendly exports
No circular dependencies
Efficient type computations (avoid deep recursion)

Files:

  • packages/localizations/src/pt-BR.ts
packages/localizations/**/*

📄 CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

Localization files must be placed in 'packages/localizations/'.

Files:

  • packages/localizations/src/pt-BR.ts
**/*.{js,ts,tsx,jsx}

📄 CodeRabbit Inference Engine (.cursor/rules/monorepo.mdc)

Support multiple Clerk environment variables (CLERK_, NEXT_PUBLIC_CLERK_, etc.) for configuration.

Files:

  • packages/localizations/src/pt-BR.ts
**/*

⚙️ CodeRabbit Configuration File

If there are no tests added or modified as part of the PR, please suggest that tests be added to cover the changes.

Files:

  • packages/localizations/src/pt-BR.ts
**/localizations/**/*.ts

⚙️ CodeRabbit Configuration File

**/localizations/**/*.ts: Review the changes to localization files with the following guidelines:

  • Ensure that no existing translations are accidentally removed unless they are being replaced or fixed. If a string is removed, verify that it is intentional and justified.
  • Check that all translations are friendly, formal, or semi-formal. Explicit, offensive, or inappropriate language is not allowed. If you find any potentially offensive language or are unsure, tag the @clerk/sdk-infra team in a separate comment. If you do not intend to tag the team, refer to it as "Clerk SDK Infra team" instead.
  • Use the most up-to-date base localization file (https://github.com/clerk/javascript/blob/main/packages/localizations/src/en-US.ts) to validate changes, ensuring consistency and completeness.
  • Confirm that new translations are accurate, contextually appropriate, and match the intent of the original English strings.
  • Check for formatting issues, such as missing placeholders, incorrect variable usage, or syntax errors.
  • Ensure that all keys are unique and that there are no duplicate or conflicting entries.
  • If you notice missing translations for new keys, flag them for completion.

Files:

  • packages/localizations/src/pt-BR.ts
🪛 Biome (2.1.2)
packages/localizations/src/pt-BR.ts

[error] 59-59: Expected a property, a shorthand property, a getter, a setter, or a method but instead found '-'.

Expected a property, a shorthand property, a getter, a setter, or a method here.

(parse)


[error] 60-60: expected , but instead found :

Remove :

(parse)


[error] 60-60: Expected a property, a shorthand property, a getter, a setter, or a method but instead found '-'.

Expected a property, a shorthand property, a getter, a setter, or a method here.

(parse)


[error] 61-61: Expected a semicolon or an implicit semicolon after a statement, but found none

An explicit or implicit semicolon is expected here...

...Which is required to end this statement

(parse)


[error] 69-69: Expected a semicolon or an implicit semicolon after a statement, but found none

An explicit or implicit semicolon is expected here...

...Which is required to end this statement

(parse)


[error] 169-169: Expected a semicolon or an implicit semicolon after a statement, but found none

An explicit or implicit semicolon is expected here...

...Which is required to end this statement

(parse)


[error] 825-826: Expected a semicolon or an implicit semicolon after a statement, but found none

An explicit or implicit semicolon is expected here...

...Which is required to end this statement

(parse)


[error] 828-830: Expected a statement but instead found ',
subtitle: 'para continuar em {{applicationName}}',
subtitleCombined: 'para continuar em {{applicationName}}',
title: 'Criar sua conta',
titleCombined: 'Criar sua conta','.

Expected a statement here.

(parse)


[error] 830-830: Expected a statement but instead found ','.

Expected a statement here.

(parse)


[error] 830-832: Expected a statement but instead found ',
socialButtonsBlockButton: 'Continuar com {{provider|titleize}}',
socialButtonsBlockButtonManyInView: '{{provider|titleize}}',
unstable__errors:'.

Expected a statement here.

(parse)


[error] 833-833: Expected a semicolon or an implicit semicolon after a statement, but found none

An explicit or implicit semicolon is expected here...

...Which is required to end this statement

(parse)


[error] 1118-1119: Expected a statement but instead found ',
removeResource:'.

Expected a statement here.

(parse)

🔇 Additional comments (14)
packages/localizations/src/pt-BR.ts (14)

17-36: New taskChooseOrganization group looks correct and consistent

Translations are clear and friendly. Key names and structure align with other sections.


69-71: Revocation flow copy matches “chave de API” terminology

Good alignment with the rest of the file; avoids “chave secreta.”


81-83: Badges: overdue labels read naturally in pt-BR

“Vencido em … / Vencido” are appropriate and consistent.


166-175: Subscription details added comprehensively

All labels are accurate and idiomatic.


179-181: Plan switch and payment view strings look good

The placeholders and unit wording are correct.

Also applies to: 185-185


204-204: Alt phone code provider action is clear

“Enviar código via SMS” is concise and correct.


283-284: API Keys titles in org/user contexts are consistent

“Chaves de API” is used uniformly across Organization and User profiles and navbar.

Also applies to: 405-406, 933-934, 1118-1120


724-724: Sign-in combined subtitle reads naturally

“Bem-vindo de volta! Por favor, faça login para continuar” is friendly and concise.


832-847: Error messages are clear and correctly localized

Short, accurate, and consistent tone. Placeholders are intact.


863-864: Enterprise connection domain error: good clarity

Matches expected phrasing for enterprise domain conflicts.


884-884: Web3 wallet missing extension message is accurate

Instruction to install the extension is clear.


1221-1225: Passkeys section CTA is correct

“Adicionar chave de acesso” matches terminology elsewhere.


106-107: Translation Verified
The Portuguese string for cannotSubscribeUnrecoverable accurately reflects the original English text (“Your existing subscription is more expensive than this plan.”). No changes are needed.


824-825: No action required: pt-BR matches en-US for socialButtonsBlockButtonManyInView
The Brazilian Portuguese entry (packages/localizations/src/pt-BR.ts line 824) uses {{provider|titleize}}, which is identical to the en-US base string (packages/localizations/src/en-US.ts line 807). Consistency confirmed.

@tmilewski tmilewski changed the title Added missing ptBR translations chore(localizations): Added missing pt-BR translations Aug 13, 2025
@tmilewski tmilewski self-assigned this Aug 13, 2025
@tmilewski tmilewski merged commit 33e7a7b into clerk:main Aug 13, 2025
11 of 31 checks passed
Copy link

pkg-pr-new bot commented Aug 13, 2025

Open in StackBlitz

@clerk/agent-toolkit

npm i https://pkg.pr.new/@clerk/agent-toolkit@6503

@clerk/astro

npm i https://pkg.pr.new/@clerk/astro@6503

@clerk/backend

npm i https://pkg.pr.new/@clerk/backend@6503

@clerk/chrome-extension

npm i https://pkg.pr.new/@clerk/chrome-extension@6503

@clerk/clerk-js

npm i https://pkg.pr.new/@clerk/clerk-js@6503

@clerk/dev-cli

npm i https://pkg.pr.new/@clerk/dev-cli@6503

@clerk/elements

npm i https://pkg.pr.new/@clerk/elements@6503

@clerk/clerk-expo

npm i https://pkg.pr.new/@clerk/clerk-expo@6503

@clerk/expo-passkeys

npm i https://pkg.pr.new/@clerk/expo-passkeys@6503

@clerk/express

npm i https://pkg.pr.new/@clerk/express@6503

@clerk/fastify

npm i https://pkg.pr.new/@clerk/fastify@6503

@clerk/localizations

npm i https://pkg.pr.new/@clerk/localizations@6503

@clerk/nextjs

npm i https://pkg.pr.new/@clerk/nextjs@6503

@clerk/nuxt

npm i https://pkg.pr.new/@clerk/nuxt@6503

@clerk/clerk-react

npm i https://pkg.pr.new/@clerk/clerk-react@6503

@clerk/react-router

npm i https://pkg.pr.new/@clerk/react-router@6503

@clerk/remix

npm i https://pkg.pr.new/@clerk/remix@6503

@clerk/shared

npm i https://pkg.pr.new/@clerk/shared@6503

@clerk/tanstack-react-start

npm i https://pkg.pr.new/@clerk/tanstack-react-start@6503

@clerk/testing

npm i https://pkg.pr.new/@clerk/testing@6503

@clerk/themes

npm i https://pkg.pr.new/@clerk/themes@6503

@clerk/types

npm i https://pkg.pr.new/@clerk/types@6503

@clerk/upgrade

npm i https://pkg.pr.new/@clerk/upgrade@6503

@clerk/vue

npm i https://pkg.pr.new/@clerk/vue@6503

commit: 8d81a8d

mwerder pushed a commit to mwerder/clerk-javascript that referenced this pull request Aug 13, 2025
Co-authored-by: Tom Milewski <[email protected]>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants